In the context of work performed by the Third Generation Partnership Project (3GPP) on System Improvements for Machine-Type Communications (SIMTC), 3GPP have introduced a feature called “time controlled” which addresses devices that can send or receive data only at certain defined time periods and potentially only need a very small time duration or interval to communicate with the network. The following is stated in Technical Report document 3GPP TR 23.888 v1.6.0, sub clause 5.9.1:
“Typically, an MTC User agrees with an operator on a predefined time period for a group of MTC devices. The time in which access is permitted is termed a ‘grant time interval.’ The network shall communicate the (altered) grant time interval to the MTC device and may also do so to the MTC Server and MTC User. A ‘grant time interval’ does not overlap with a ‘forbidden time interval.”
Such a grant time period or grant time interval is allocated to a device, in the above example a Machine-Type Communications (MTC) device, for the device to communicate during the grant time interval and not outside the grant time interval.
Technical Report document 3GPP TR 23.888 v1.6.0, sub clause 5.9.1 goes on to state (comments added in square brackets):
“For many applications, individual MTC devices do not need the total duration of this predefined time period to communicate with the MTC Server. Typically a 5-10 minutes communication window is sufficient for an individual MTC device” [to communicate with the network at any one occasion].
A network operator may therefore define a ‘communication window’ for a device to communicate, the communication window being within the grant time interval and having significantly smaller duration than the grant time interval. The network operator can find it advantageous to limit or minimize the duration of such a communication window, as will become apparent from the following description. Technical Report document 3GPP TR 23.888 v1.6.0, sub clause 5.9.1 goes on to state (comments added in square brackets):
“To avoid network overload [and peaks in signalling data and/or traffic data] . . . the communication windows of the devices shall be distributed over the defined time period [so that overlap of communication windows is minimized or avoided] . . . e.g. through randomization of the start time of the individual communication windows [within the grant time interval]. For a network operator, it can be beneficial that the MTC devices are not attached outside their [respective] communication window[s]. Therefore the network operator should be able to enforce detach of an MTC device from the network at the end of the communication window of a device.”
There is one communication window allocated per wireless device/terminal, although there is no restriction that the device would communicate just once during the grant time interval. The grant time interval is the time during which the terminal is allowed to communicate. The time during which the terminal actually communicates with the network is called the ‘communication window’. There is normally one such window per device but there could be more, depending on the MTC application (use case).
The grant time interval schedule (information) is delivered to the terminals by the network. As the same grant interval usually is delivered to a large number of MTC devices, it is beneficial that these MTC devices do not start communication at the same time (at the beginning of the grant time interval, for example) because that could cause temporary overloading of the channel used for the communication by the devices. The timings of the communication windows are randomised by the network. The network may deliver a randomisation information which indicates a time when each terminal is to start its communication (communication window), the communication windows being within the grant time interval.
Because of the introduction of communication windows, the times at which detach signalling occurs can be predicted.
With machine-type communications, signalling overload is expected to become a significant issue for networks as networks will face more and more connected devices due at least in part to the introduction of Machine Type Communications devices and this will result in potential signalling overload, simply due to the increased number of devices that can be attached to the network at any time. It would be beneficial to reduce the detach signalling which will likely occur at the end of the communication window (when communication windows are used) or at the end of the grant time interval (when communication windows are not used).
There are currently two different mechanisms in 3GPP systems for detaching a device (which could be any wireless terminal e.g. a mobile phone, fixed terminal or MTC device). Although these mechanisms are described herein in relation to a 3GPP system (e.g. GSM/GPRS, UMTS, Evolved Packet System (EPS)), it should be understood that other non-3GPP wireless communication systems have similar mechanisms for performing a detach operation or an equivalent of a detach operation, and aspects of the present invention described herein can apply equally to such other systems. The 3GGP mechanisms can be summarized as follows:
1) In a device-originated detach procedure, the device sends a DETACH REQUEST message to a network, and the network may acknowledge the DETACH REQUEST message (depending on resource availability for example) by sending a DETACH ACCEPT message, provided that the DETACH REQUEST message is not due to the device having been switched off, e.g. by a user of the device holding down a power-off button on the device.2) In a network-originated detach procedure, the network sends a DETACH REQUEST message to the device, and the device acknowledges the DETACH REQUEST message by sending a DETACH ACCEPT message to the network.
While both the above mechanisms seem viable solutions, it should now be appreciated that in the following situations detach signalling has limited usefulness:
a) a situation in which the device attaches so that it can transmit a data transmission that is smaller than an average transmission by devices in the system;
b) a situation in which multiple devices are allocated or assigned (e.g. by the network) different communication windows, and at the end of its communication window each device will not communicate any longer with the network until the next-occurring communication window;c) a situation in which the device is assigned or allocated a grant time interval, and at the end of the grant time interval the device will not communicate any longer with the network until the next grant time interval.
Additionally, both mechanisms 1 and 2 above require a signalling connection. In particular, when the device and the network are not connected any longer (for example after a loss of radio connection e.g. due to a poor signal path condition), additional signalling is required to again establish such signalling connection.
According to all of these considerations, increased signalling will arise when an increased number of devices are deployed in the communication system, and in particular when a large number of MTC-type devices are deployed in the communication system.
In GSM/GPRS and UMTS systems, an ATT flag (transmitted on a broadcast channel (BCCH) as part of System Information) can indicate to a device whether or not a detach procedure is actually required. This flag can potentially give a limited possibility for the network to reduce signalling load due to devices detaching. 3GPP technical specification document TS 24.008, sub clause 4.3.4 states:
“In A/Gb mode and GERAN Iu mode, a flag (ATT) broadcast in the L3-RR SYSTEM INFORMATION TYPE 3 message on the BCCH is used by the network to indicate whether the detach procedure is required. The value of the ATT flag to be taken into account shall be the one broadcast when the mobile station was in MM idle. In UTRAN Iu mode, a flag (ATT) in the CS domain specific system information element is used by the network to indicate whether the detach procedure is required. The value of the ATT flag to be taken into account shall be the one received when the mobile station was in MM idle.”